Cosense開発にClaude Codeを使った感想
初見ではDevinの簡単かつ手元で動くバージョンという感じshokai.icon 同じところ
自然言語で指示したら、自然言語で作業プランを設計して、個別のタスクをさらに分解して、最終的にUNIXコマンドの連鎖まで落とし込んで実行しているっぽい
概念や戦略を伝えて、大規模にやらせて、ちゃぶ台返しても怒らない 違うところ
作業中に横から追加で指示を突っ込めない
キャンセルして追加指示する事はできる
まあ実際これで困っていないshokai.icon
速い
安い
同じ様なレビュー作業させてもDevinは3 ACUs前後かかるけど、Claude Codeは$1かからない
ローカルで作業してくれる
自分と同じUNIXコマンドを実行させれる
ローカル開発環境のサーバーログやビルド失敗ログを直接読ませれる
Claude codeは終了するとsessionは消える
Devinは数週間前のsessionでも再開できる。Devinにレビュー依頼して、自分で修正作業して、根本的な質問が生じた時に質問し直したりできる
しっかり変更箇所のdiffを見せて了解を取ってくる
エイヤでやれないプロダクションコード作ってる人にはありがたいshokai.icon
終了したらsessionを復元できない性質と合わせて考えると、Devinよりももっと小さい単位で作業させていくべきだろう
あるいは最初にclaude codeに作業計画を生成させて、個別のタスクに分解させ、人間が監修・調整し、それぞれを別々のclaude codeに作業させるような、大規模開発の模倣をするべきかもしれない
ローカルで作業してくれるから交互に高速に餅つきみたいに作業できて良いshokai.icon*10 claude code上でUNIXコマンドを打つ事で出力結果を一緒に見て、支援を受けれる
作業を終えた後「同じ様な事やるべき場所あったっけ？」と聞くと「あったので、やっておきました」になる
途中まで自分でやってから「このディレクトリの中ぜんぶ同じ感じで続きよろしく」でやってくれる
hiroshi.icon これ具体的にどうやるんだろう? そのうちわかるか?
だんだん加速する
ファイル編集した後はlintかけてからcommitしてpushするべきなんだな、と空気を読み始めて、だんだん一連の作業をセットでやろうとしてくる
眼の前の作業が、さらにAIに食わせてスケールさせる事を前提とした、もう1つ新しい意味を持った作業になる
作業結果を分析させてガイドラインを生成し、人間が監修・修正する。ガイドラインに基づいて別のAIに作業させる
常にこれを考えてドキュメント蓄積して自動化していった方が良いので、Devinのようなみんなで共有してSaaS上で動くAIと、手元で動くAIの2つを併用した方が良い AIと一緒に作業した結果をドキュメント化して、チーム内で共有していく
手元・SaaS上の片方のAIエージェントしか使っていない場合、この感覚がわからないかもしれないshokai.icon
とはいえ、作業は速くて知識はけっこうあるけど大局的な判断はわりとよく間違える、結局AIなので、俺が方向修正したり根本的なミス指摘しないとダメだなコイツと思うシーンは毎sessionあるshokai.icon
まあでも基本的にDevinみたいなものなので、Devinのアクセス権限持ってて見てこういう事させれるのではないか？という想像力が働かなかったり、使う欲求が出てこない人には不要なツールでしょうねshokai.icon
1 sessionで$5超える前後ぐらいから重くなってくる
頻繁にchat historyの圧縮をするようになる
ビミョーに作業も遅いような
命名規則を説明した上でのリファクタリングにかなり便利 1200行ぐらいのプルリクを700行ぐらい直した
https://gyazo.com/a553e0a6000edaa292e6a13497e3b713
変数や関数の名前が「access key」だったり「service account key」だったりで、ブレがあったので
命名規則を説明して、揃えるようお願いした
shokai.icon「機能の正式名称はService Account Access Keyです。そのデータモデルはService Accountで、そのfieldとして.accessKeyがある。この命名規則と合ってない所を全部直してくれ」
「たとえばService Account Keyになってる所とか」
直接指示した部分も多いけど、基本は概念説明からの具体化で進めた
で色々相談しながら進めていたら、命名規則に則ってリネームされてよかったshokai.icon
serverもclientのstoreも、React上のUI文言も統一できた
指示してないのにファイル名も一緒に変更してくれた
UIの表示文言まで漏れなくやってくれたのは驚いた
SPAなので、どのコンポーネントがどのURL pathで表示されるか微妙にわかりにくいはずなのだが
「このブランチで変更したファイルを対象に、文言を揃えるリファクタリングをしたい」という作業範囲をコントロールする指示を最初にしていたのが効いたのかもしれない
同じ文言がディレクトリ名とファイル名に重複して書かれている箇所が綺麗になった
例：/service-account-settings/service-account-access-key.js
表記方法の空気を読んでやってくれる
ちゃぶ台を返せる
「やっぱこういう名前にして」で気軽にやり直せる
人間相手ではこれができない
ダメだった所
数か所だけ、「serviceAccountServiceAccessKey」みたいな訳わからん名前にしようとした部分があったが
1つずつ確認しながら進めたので、「それは違うよ」と指摘して事なきを得た
設計時にしっかり名前付けてから実装開始する必要がなくなった？shokai.icon
実装して、機能を触りながら命名した方がやりやすい
API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"You have reached your specified API usage limits. You will regain access on 2025-04-01 at
お金が足りないのか？オートチャージ設定してるはずだけど、と思ったが
月毎のlimitにひっかかっていただけだった
自動的にsonnet 3.7とhaiku 3.5を使い分けているようだshokai.icon https://scrapbox.io/files/67f2cea14c2b8163ce4a2928.png
作業内容によるのかな
いちいち作業前に確認せずにコマンド実行するモードがほしいshokai.icon
https://gyazo.com/f4615ccbd6d52e4a08f1e5a4f318b261
これある気がしますteramotodaiki.icon
claude --dangerously-skip-permissionsでした。でもDockerの中でしか動かないらしい
いや、Shift-Tabらしいteramotodaiki.icon
shift + tabはファイル編集の確認スキップですねshokai.icon
同じコマンドを2回目実行する場合は「次は確認求めずやれ」ができるけど
異なるコマンドを駆使して色々やる場合は、「次は確認するな」が効かない。全て個別に許可する必要がある
https://scrapbox.io/files/67f2ceb04c2b8163ce4a295a.png
4月頭ごろから、同じコマンドではなく似たコマンドという括りで許可するようになって面倒が少なくなった気がするshokai.icon
DevinとClaude Codeと自分の3つを併用するのがとても気持ち良いshokai.icon
自然言語でやりたい事を説明すると、具体的なコマンドや作業手順を提案してくれる
「実行して」と伝えれば実行してくれる
別のAPIの実装を参考にしてstreaming処理を実装させた
指示してないエラー表示まで実装してくれて便利だった
あるbugfixをした後、同じ修正をやるべき場所は他にある？と聞いたら探して直してくれた
CLIに慣れている人がさらにCLIを便利に使えるshokai.icon
claudeにgit diffと伝えると、普通にgit diffを表示しつつ解説してくれる
同様にgit commitとかpushとかもできる
commit message考えてくれる
ローカル開発環境を整えるのをやってもらった
GNU screen上でclaude codeの絵文字が文字化けしてたので、自分が使っているscreenと同じ操作感のtmuxの設定を作って移行してもらった tmux入れたらemacsが3つメジャーバージョンアップして動かなくなったpluginがあったので、別のpluginに差し替えてもらった emacs 27から30に上がった事を検知はしてくれなかった
私も最初は気づかなかった
「いつのまにかemacsが3つ上がってて〜」と言ったら「じゃあこのplugin古いから新しい別のやつにしましょう」となった
現在のブランチと指定ブランチの間で変更があったファイルをまとめてemacsで開くコマンド、pathの入力補完つきを作ってもらった
ローカル開発環境でprettierがうまく動かない理由を調査してもらって、修正もしてもらった https://gyazo.com/9edc3414286721315a668b63d07a392e
この後sass-modeが動かないって言ったらしばらく調査した後、web-modeに変えましょうと言われて、入れ替えてくれた
ライブラリの中身のbugを解析してもらい、アプリケーション側で対応した
このへんの、適当なタイミングで作業ターンを返してきたり、途中で質問してきたり、あるいは質問なしで一気にファイル変更からtest実行してgit commitまでやろうとするような挙動がやたら自分と波長が合うshokai.icon
だんだん加速する
最初は「git commit」とか「pushして」とか言う
次の作業をさせると、自発的に「commitしましょう」（y/n）と提案してくる
最初は「その作業ならこのファイルからやると良いと思います」とか言ってたのに、次の次ぐらいからは「このファイルをこうすると良いです、diffはこれです、保存していいですか？」になる
変更規模が大きくなってくるとgit commitしたそうな雰囲気を出してくる
作業指示をしたら、作業した後、さらに自発的にgit commitしましょうと言ってくる
それでも「まだ関数直しただけなので、関数を使う側のコードも直しましょう」となだめながら作業させると、すごくcommitしたそうな雰囲気になる
作業Aをやらせながら、途中で「先に作業Bをやりましょう」と脱線すると、Bを終えた後Aを自発的に提案してくる
だんだん私も「あと何をやるべきだっけ」とかclaude codeに聞くようになる
ちゃんと覚えててくれて作業リストを出してくる
git rmとかgit pushとかを次から許可なくやっていい、という記憶がsession毎なのも、ちょうど良い塩梅なのかもしれないshokai.icon
だんだんすごい勢いでTypeScriptに翻訳したがって進めようとするので、なだめてる
https://gyazo.com/99acffa6d8e518d8050cc880924d4d5d
一通り全て実装し、最後に変数名・関数名・ファイル名が気に入らない箇所があったので一括変更してもらった
Reactコンポーネントのリファクタリング（分割）やってもらった